Node failover recovery is one of the critical components of a distributed database hosted on a shared disk cluster (SDC) infrastructure. Node failover involves recovering from uncommitted changes performed by tasks at the failed node in the SDC environment, as well as restricting access to the affected data items until the data items come to a consistent state. For example, access is restricted by using proper concurrency control locks acquired on the uncommitted data items by the node performing the failover recovery of the failed node. There are various mechanisms developed to detect the identity of the uncommitted data items of the failed node. One of the commonly used mechanisms is to replicate transaction lock information while the locks are acquired by the active tasks. For example, during the course of the transactions, the threads accessing the data item acquires a lock on the data item, and the lock information is replicated to the other nodes in the cluster. When the node having active transactions goes down (failure of the node), then the node recovering the changes of the failed node will restrict the access to the uncommitted data by using the replicated lock information. In some cases, the failover recovery of a node in the distributed database hosted on shared data devices involves rebuilding the locks space using the replicated locks, acquiring locks (e.g., locks associated with incomplete transactions at the failed node), and recovering the database to a consistent state. The access to the effecting database is restricted until the locks are acquired by the failover recovery thread. As the locks are replicated with the intention of supporting the failover recovery, every transaction has to follow the protocol and creates lock replicas at the other node. If the transaction is committed, then the replicas are not useful and need further cleaning. This is a computationally expensive operation because: (a) the number of lock resources is increased (at least doubled) in the system; (b) it involves expensive messaging across the nodes while acquiring the locks and will impact the throughput of the system; and (c) it adds more work to the garbage collection thread of reclaiming the lock resources.